One of the underpinnings of location-based services such as emergency services is the ability to determine the physical location from which a call has been made. For example, when an emergency call is made in the public switched telephone network (PSTN) using a plain old telephony service (POTS) phone, the emergency call sent through the PSTN specifies the directory number of the POTS phone. Due to the way in which the PSTN is configured, the directory number of each POTS phone corresponds to a fixed physical location (e.g., service address), and this relationship is maintained in an ALI database made available to PSAP operators. Thus, upon handling an emergency call specifying a given directory number, a PSAP operator who queries the ALI database using the given directory number will learn the address from which the emergency call was placed and, consequently, to which an emergency crew needs to be dispatched.
As voice-over-internet-protocol (VoIP) becomes the predominant technology used in the telecommunications industry, customers using VoIP devices (hereinafter “VoIP customers”) will expect emergency services to be delivered when emergency calls are originated from such devices over a broadband network. However, some broadband service providers' networks are not natively compatible with the existing emergency infrastructure described above. In order to allow the delivery of emergency services to VoIP customers in a broadband network, the National Emergency Numbering Association (NENA) has proposed various architectures that can interface with the existing emergency infrastructure, thereby allowing existing PSAPs to handle emergency calls placed by VoIP customers.
Compounding the need to address the aforementioned issue of incompatibility with the existing emergency infrastructure is the need to address the issue of determining the physical location of the VoIP device from which an emergency call is originated. Specifically, because telephone numbers assigned to VoIP devices are not necessarily associated with a fixed address or location, the availability of the directory number of the VoIP device is not sufficient to allow the physical location of the VoIP device to be determined. This problem also prevents service providers from offering other location-based services to their VoIP customers.
In order to resolve the above issue in the emergency services context, NENA has proposed a so-called “i2” architecture, which provides a network element known as a location information server (LIS) that serves as a repository for location information. The LIS is configured with a mapping between, on the one hand, location information elements (in the form of civic addresses or geo-spatial location attributes) and, on the other, logical representations of the respective physical locations with which the location information elements are associated.
Using the LIS, VoIP devices will be able to receive information on their own physical locations so that this information is conveyed during an emergency call. Alternatively, a VoIP device may be assigned a unique key that is used as an index to the LIS, which key is conveyed during an emergency call and can be used to consult the LIS for the purposes of obtaining the physical location of the VoIP device.
However, one significant omission from NENA's proposed i2 architecture is any description of how to populate the LIS with accurate information. In fact, document NENA 08-001, Issue 1, Dec. 6, 2005, entitled “Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)”, hereby incorporated by reference herein, plainly states that “How the IP network actually determines the location and the protocol between the LIS and IP device is outside the scope of this document”. Thus, there remains a need for a solution to the problem of determining a VoIP device's location, in order to enable the LIS to be populated.